
/flOflPOS™ FAQ 

What is an FAQ? 

An FAQ is a list of frequently asked questions. In addition to supplying 
background material, this document will provide answers for the most 
frequently asked questions about JavaPOS, posted by visitors to our website 
(see http://www.javapos.com). 

What is JavaPOS? 

It was recognized early on that the emergence of the Java language on the 
computing scene offered several major advantages to the developers of retail 
applications. 

The JavaPOS (Java for Point Of Sale) standard committee was formed by a 
collection of retail vendors and end users to examine the ways in which these 
Java advantages could best be exploited in the retail environment. 

The original JavaPOS programming standard (vl.2) was the end result of ten 
months of effort by this committee. It was followed by JavaPOS vl.3, which 
defined Java interfaces for three additional retail POS devices (Fiscal Printer, 
PIN Pad and Remote Order Display), and JavaPOS vl.4, which added the 
Credit Authorization Terminal (CAT) interface requested by Japanese retailers. 
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What is the relationship between the OPOS and JavaPOS standards? 

The OLE Point of Sale (OPOS) standard architecture was used as the starting 
point for the JavaPOS effort. There were several reasons for this approach. 


OPOS was a good first step 

The primary goal of OPOS is to permit retail application developers to be 
independent of the proprietary details (ex: special escape sequences) of the 
retail peripheral devices they accessed. 

This was the starting point for the larger goal facing the JavaPOS committee: 
to permit the retail application developer to be independent of the 
proprietary details of BOTH the peripheral devices they access AND the 
POS platform on which the application itself runs. For example, the 
JavaPOS standard eliminates the OPOS dependency on the NT Registry. 


Reuse of Retail Peripheral Device Models 

Over 90% of the voluminous OPOS documentation is devoted to specifying 
the properties, events, methods and error codes of the seventeen (as of 
OPOS vl.3) defined retail peripheral devices. 

These device models are both language AND platform independent, which 
allowed their direct incorporation into the JavaPOS standard. 


Reduced Learning Curves 

Many retail application developers already had experience using the OPOS 
APIs, and many retail hardware vendors had experience implementing the 
OPOS Control APIs. 

Adopting this approach therefore reduced the learning curve for the very 
audience JavaPOS was targeting. 
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Two-Phase Deployment 

By sharing the same device models as OPOS, it becomes possible to use a 
generic "OPOS bridge" to map existing OPOS Device Controls and Services 
into their JavaPOS equivalents. One example of such a bridge has long been 
made freely available by Wincor Nixdorf, and others have been created by 
NCR and Datafit Corporation. 

This bridging capability provides a means of profotyping and festing 
JavaPOS-complianf retail applications on existing OPOS terminal 
configurations. 


What is the relationship between the UnifiedPOS and JavaPOS standards? 

The Unified Point of Service (UnibedPOS) committee was formed by the 
Association for Refail Sfandards (ARTS) under the auspices of the National 
Retail Federation (NRF), at the request of leading refailers in fhe Unifed States. 
It was created to ensure that future (post vl.3) releases of JavaPOS and OPOS 
would confinue fo share the same POS device architecture (i.e. each defined 
device type would possess the identical set of properfies, mefhods and evenfs 
in bofh sfandards). 

The resulfing UnifiedPOS refail device standard (see http://www.nrf-arts.org) 
is primarily defined in Unified Modeling Language (UML) and is fhus bofh 
O/S independent and language neutral. 

The UnifiedPOS fechnical commiftee draws ifs membership primarily from the 
JavaPOS and OPOS committees. Both committees have agreed that any new 
retail device type (ex: ForeCourt) will first be modeled in UML and added to 
the UnifiedPOS sfandard. Only after such UnifiedPOS approval is obfained, 
will the device UML be mapped to the Windows/OLE platform (by OPOS) 
and fo fhe Java plafform (by JavaPOS). 

As a resulf, sfarfing wifh fhe vl.4 version, a formalized procedure was puf in 
place to ensure that both the OPOS and JavaPOS specification will continue to 
contain the identical interfaces (properfies, methods and events) to an identical 
set of refail devices. 
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What are the advantages that JavaPOS brings to retail Point of Sale? 

POS systems which are conformant to the JavaPOS standard provide several 
significant advantages for fhe refailer. 


Reduced POS Terminal Costs 

Applications written in the Java language execute by having a Java Virtual 
Machine (JVM) interpret their platform independenf byfe codes. These 
applicafions will fherefore execufe wherever such a JVM is presenf 

By lowering fhe minimum requirements for a Poinf of Sale ferminal fo a 
system capable of supporting a single JVM, the JavaPOS standard enables 
retail applications to be run on thin client platforms which are often less costly 
than more traditional Windows PC configurations. 


Platform Independence 

The JavaPOS standard utilizes the JVM as its retail platform, whether present 
in a browser, an operating system, or directly embedded within the microcode 
of a specialized compufer chip. 

This language-cenfric plafform is decoupled from any hardware or operafing 
system specifics. Therefore a JavaPOS-complianf refail applicafion is capable of 
rurming equally well on a fhick clienf Windows95/98, SCO, IBM 4690 or Linux 
operafing sysfem, or on a fhin clienf SunRay, IBM 4690, Linux, Windows-CE or 
Palm OS based sysfem. 

The only remaining propriefary elemenf in a JavaPOS-complianf refail 
applicafion is fhen fhe applicafion code ifself. 


Reduced administration costs of thin clients 

The capability of the Java language platform fo reside on thin clients offers 
addifional cosf savings to those sites that run JavaPOS-compliant applications. 

If fhe clienf porfion of a refail applicafion is wriffen as a Java applef or loadable 
applicafion, all of the application code resides on the in-store server. This 
means that installing or upgrading the POS software on the server results in 
the automatic loading of the new software into each local POS terminal, when 
the terminal is next booted. 
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The system administrator need only install a retail application once, and it 
becomes installed ever 5 rwhere in the store. Fix the application once, and it is 
fixed everywhere. 

The absence of persistenf sforage on a thin client also eliminates the need to 
perform POS terminal data backup and recovery. However local disks could 
still be useful fo cache pricing information and outgoing purchase transaction 
data, so as to allow the thin client POS terminal to continue to function 
effectively, even if the server connection was lost for an exfended period of 
fime. 

For sites with large numbers of POS ferminals, fhese advanfages can result in a 
considerable savings in system administrative overhead costs. 

Is JavaPOS a complete standard? 

JavaPOS is a complete standard for retail point of sale systems in exactly the 
same sense that OPOS is. 

It maps the UnifiedPOS retail device architecture to the Java platform. Thus 
a JavaPOS configuration encompasses most OPOS hardware/software 
configurations, as well as a wide range of ofhers. 

If sfandardizes fhe Java interfaces used by retail POS applications (the 
Device Controls) to access and control POS devices. 

It standardizes the internal interface used by these Device Controls to locate 
and load the set of device drivers (Device Services) appropriate for fhe POS 
ferminal configurafion, via the Java Configuration Loader (JCL). 

It standardizes the interfaces supported by these Device Services, which 
must respond to requests from fhe JavaPOS applications (as relayed through 
the corresponding Device Control), and pass back asynchronous events. 

It references fhe JavaComm API which allows pure Java Device Services to 
locate and access their respective peripherals for RS 232 type devices. For 
other device attachment options such as RS 485 and USB, the Device Service 
must (currently) still access the individual OS-specific porf protocol routines 
directly. 
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Working implementations for all the above JavaPOS components except the 
Device Services (typically supplied by the device manufacturer) and of 
course fhe JavaPOS applicafion ifself, are freely available (eifher direcfly or 
fhrough linkage) on the JavaPOS website. 

What are the exact JavaPOS Deliverables? 

The JavaPOS standards committee has produced the following sef of 
deliverables: 


JavaPOS Architectural Whitepaper 

This whitepaper describes the philosophy and architecture of fhe JavaPOS 
sfandard and serves as an infroducfion to the other documents. 


Java for Retail POS Programming Guide 

This 600+ page document defines the JavaPOS standard. It is comparable in 
many ways to both the OPOS Application Programmer's Guide and the 
OPOS Control Programmer's Guide combined. It specifies fhe applicafion- 
level Java language inferface to the set of all defined retail peripheral 
devices, as well as the APIs for fheir corresponding Device Services. 


JavaPOS Frequently Asked Questions (FAQ) List 

Answers to a set of frequently asked questions concerning the JavaPOS 
standard. You are in fact reading this FAQ now. 


JavaPOS Source Files 

These files provide the foundation upon which JavaPOS-compliant 
applications and device services must be constructed. They are all available 
on the JavaPOS web site. 

1. Codes 

The collection of all JavaPOS stafus and error codes 
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2. Exceptions and Events 

The set of all defined JavaPOS Excepfion and Evenf subclasses 

3. Refail Device Confrols 

The base Device Confrol Inferface, and for each refail device cafegory 
(ex: Scanner, Cash Drawer): 

a. A derived JavaPOS Device Confrol Inferface (currenfly vl.4) 

b. A sef of Device Confrol consfanfs 

c. A complefely implemenfed Device Confrol class 

4. Refail Device Services 

The base Device Service Inferface 

A derived JavaPOS Device Server Inferface (currenfly vl.4) for each 
cafegory 

A sample device service. 


JavaPOS Configuration /Loader (JCL) 

The jpos.config/loader (JCL) is a simple binding (configurafion & loading) API 
which allows a JavaPOS confrol fo bind fo fhe correcf JavaPOS service in a 
manner independenf of fhe acfual configurafion mechanism. Por POS 
applicafions, if represenfs a somewhaf minimum (buf exfensible) funcfional 
equivalenf of fhe NT Regisfry. 

All JavaPOS Device Confrols (vl.4 and above) provided on fhe JavaPOS 
websife will use fhis API. 

A reference open source implemenfafion of fhe JCL is also available on fhis 
websife, mainfained by IBM and fhe JavaPOS fechnical commiffee. This 
reference JCL comes complefe wifh JavaDoc documenfafion, examples, sample 
code, a browser-based configurafion edifor and ifs very own PAQ. 
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Can I construct a 100% pure Java solution for retail POS? 

By combining the above software on the JavaPOS website with the publicly 
available JavaComm v2.0 API and platform implemenfafions (see 
hffp://java.sun.com/producfs/javacomm), if now becomes possible to 
construct COMPLETE Java based solutions for refail POS, fhaf include 
platform-neufral retail applications as well as platform neufral device services. 

Essenfially: 

• The Device Services use the JavaComm API to access device port data 
streams. 

• The Device Controls use the JCL API to determine which Device Services 
correspond to the hardware devices connected to a particular POS station. 

• The Applications use the various Device Control APIs to access and control 
these devices. 

and the implementations for all fhree (as well as fhe source code for fhe lasf 
two) are, as indicated, openly available on the net. 

How do you deliver JavaPOS on a Windows Terminal 

There is a choice: you can either use Pure Java Device Services (which can 
support their peripherals on multiple platforms) or you can use an OPOS 
bridge. In eifher case, fhe JavaPOS applicafion is unaffecfed. 


Platform-neutral Java deployment 

Windows 95 and Windows NT sysfems can be converted into JavaPOS 
platforms wifh fhe addifion of fhe 100% pure Java JVM, and fhe Windows 
implemenfafion of fhe JavaComm API (bofh freely available from fhe JavaSoff 
websife). 

By combining a full complimenf of JavaPOS complianf Device Services with a 
JavaPOS compliant application, the entire retail system (application and device 
drivers) becomes portable. 
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It becomes possible for example to load Linux onto the same Intel 
configuration, reboot, and aside from edifing a single configurafion file, have 
fhe same applicafion access fhe same sef of refail peripherals, USING THE 
EXISTING SET OE DEVIGE SERVIGES. No code modificafion or recompiling is 
required. 


Windows-only Java deployment 

Alfernafively, if you do nof have pure Java Device Services for fhe devices you 
wanf fo drive, buf do have preexisfing OPOS drivers, you can use a 
JavaPOS/OPOS bridge. Nofe fhaf such bridges are nof 100% pure Java, as they 
must invokes native code written in G. 

Any true JavaPOS/OPOS bridge must deliver the complete JavaPOS 
fimctionality to a Java POS application using OPOS drivers. It it possible to do 
so because the device functionality of JavaPOS exacfly mirrors thaf of OPOS. 
Such bridges have been deployed by cusfomers of Wincor Nixdorf and 
demonsfrafed by NCR and Dafafit, and ofher companies have developed fhem 
as well 

Nofe thaf JavaPOS applicafions ufilizing a JavaPOS/OPOS bridge can be 
subsequenfly redeployed on another operating system (ex: Linux) without 
modification, although a new set of device services (based upon JavaComm, or 
specific fo fhaf OS plafform) would have fo be obfained. 


When can I start implementing my own JavaPOS solution? 

The JCL is available foday as a 100% pure Java package fo configure the POS 
terminal and provide linkage from fhe JavaPOS Device Confrols fo fhe Device 
Services layer. All fhe JavaPOS Device Confrols are also implemenfed and 
available. 

By adding an OPOS bridge over an exisfing sef of OPOS drivers (see above), 
JavaPOS-complianf refail applicafions can be wriffen today and deployed on 
Windows 95/98/NT systems. 

Likewise, fully complianf JavaPOS solufions can be deployed foday on 
Windows 95/98/NT, IBM's 4690 OS Version 2, Solaris and Linux, provided 
fhere is access fo a corresponding Java Device Service for each configured POS 
hardware device on fhe sfafion. 
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How do I get my comments in for consideration by the JavaPOS committee? 

Post them directly from the JavaPOS web site. All such comments will be 
reviewed and responded to by members of fhe JavaPOS commiffee. 

Is it possible to write efficient, robust 100% Pure Jam device drivers? 

The part of a device driver thaf needs fo be so efficienf fhaf you mighf consider 
wrifing if in assembler, or af least C, is the low-level port handling. With Java, 
the handling of fhe serial, parallel or (soon) USB porf ifself is done wifhin fhe 
Java Communicafions 2.0 API implemenfafion. Supporf for fhis API is 
available foday from JavaSoff for fhe JDK 1.1.4 release and above on Solaris or 
Windows, and is available externally for Linux. 

The JVM which execufes fhe Java byfe codes of fhe device driver is compiled 
from nafive code for fhe fargef machine, using assembler or C, as fhe JVM 
wrifer deems appropriafe. 

The 100% pure Java Device Service is fhus given plafform independence and is 
responsible only for franslating fhe byfe sfreams between the program and the 
relevant port. For instance, it might interpret a program command "cut paper" 
as "Escape X Y". 

The Java language is ideally suited to doing this kind of franslafion, and, in 
pracfice, delivers more fhan adequafe efficiency, especially when fhe driver 
code has been precompiled or JIT (Jusf In Time) compiled. In fhe laffer cases, 
fhe overall performance of Java is comparable fo nafive-mode compiled C++. 


How do I migrate from an OPOS to a JavaPOS solution? 

A clear OPOS fo JavaPOS migration strategy exists. Its overarching goal is to 
"free" existing POS applications from fheir dependency on fhe Windows 
operafing sysfem, and allow end users and ISVs fhe same flexibilify in 
selecfing an OS and hardware platform vendor thaf fhey have foday in 
selecfing among mulfiple suppliers for each POS device type. 

In brief, fhe sfrafegy consisfs of a few well defined sfeps: 
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1. Use an OPOS bridge to access existing OPOS Device Services. This allows 
JavaPOS-compliant applications to be written and deployed immediately 
which support the set of existing devices in the store. Such deployments will 
be limited only to thick-client Windows-based systems however. 

2. As true JavaPOS-compliant Device Services appear (developed and tested 
on any platform which supporfs fhe JavaComm API ... including Windows) 
fhe OPOS bridge begins fo "narrow". Once fhe lasf pure Java Device Service 
appears, the OPOS bridge can be discarded altogether. 

3. At this point the entire retail POS application (including the JavaPOS Device 
Services) may now be installed and run on ANY JavaPOS-compliant 
platform (fhick or fhin clienf) wifhouf furfher change. 

How can I prepare for JavaPOS ? 

Three main areas need fo be addressed in your IT planning for JavaPOS: 
infrasfrucfure, assef reusabilify and organizafion. 

For infrasfrucfure, you will minimally need fo supporf TCP/IP on fhe local 
area network in the store. If IP is nof presenf you will need to develop an IP 
addressing scheme and determine how you are going to administer it. DHCP 
and DNS will provide lots of flexibilify buf you will need fo archifecf 
addressing properly and consider fhe impacf on your enferprise. 

Depending on the size of your stores and your Wide Area Network (WAN) you 
may need an httpd process running on your in-store servers. You will need to 
budget head count and capital for fhe infrastructure improvements. If you are 
jusf getting started with an IP WAN make sure to address security issues up 
front. Firewalls and access lists will affect your network design and overall 
cost. 

Asset reusability planning refers fo defermining if your exisfing regisfers and 
servers can be ufilized. Depending on your requiremenfs fhey may need fo be 
upgraded or replaced. While your vendor may offer some assisfance, you 
should dedicate some staff to prototyping and evaluating after market upgrade 
solutions. You have to consider both the hardware characteristics and the 
operating software you are going to use. The registers are likely to run a DOS 
variant or MS Windows now, with possibly Linux as an option for fhe fufure. 
The invesfigafion efforf should provide defails for fhe capifal plan. 
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If you outsource development the organizational impact is minimized. If you 
develop your own applications you need to consider if your staff is capable of 
taking on a new development paradigm. Determine the level of training your 
existing persormel need and whether you need to supplement their skills with 
new hires and/or consultants. It would be wise to pick a small project and use 
this as a training opportunity for your team. A kiosk project for example may 
be a good one to gain experience on before taking on POS. During the test 
project, validate everything; object design skills, development tools, operating 
environment, .... 

You also need to determine if your organization's structure will complicate 
things and if so, whether you need to reorganize. An advantage of writing in 
Java is the ability to reuse objects across a variety of platforms. For example, a 
POS object could be used in a handheld terminal or in an internet application. 
If the POS, handheld and internet programming is done in three distinct 
groups you have to accoimt for extending the object for specific needs and the 
impact one groups changes will have on the others. You may need to establish 
"owners" of reusable objects to avoid versioning problems while leveraging 
existing expertise. 

What about international coverage? 

With their international perspective, the JavaPOS-Japan committee members 
have ensured the applicability of JavaPOS to the Japanese market. A complete 
Japanese translation of all key JavaPOS documents is directly accessible from 
the JavaPOS website. 

What are JavaPOS plans for 2000? 

Under the current arrangement, all future retail POS device specifications will 
be issued by the UnifiedPOS committee, and then adopted simultaneously by 
the JavaPOS and OPOS committees. 

The JavaPOS committee will therefore concentrate on: 

• Mapping new UnifiedPOS device specifications to Java 

• Organizing "cormectathons" between developers of JavaPOS retail 
applications and device services 

• Supporting the software (Device Controls and JCL) currently available on 
the JavaPOS website 
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• Providing a focal point for JavaPOS expertise and serving as the primary 
means of communication between JavaPOS developers 
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